(レポート) TLC301 : Always Online: Real-Time Communications on AWS #reinvent

セッション「TLC301 Always Online: Real-Time Communications on AWS」を聴講しましたのでレポートします。スピーカーは

• Shoma Chakravarty - WW Technical Leader, Telecom
• Ahmad Khan - Sr. Solutions Architect, Amazon Web Services

です。本セッションではキャリアグレードな音声コミュニケーションシステムについてSIPとWebRTCを中心に紹介します。

Use Cases

まずはユースケースの一覧。

Typical Architecture

アーキテクチャの比較。オンプレの場合。

AWSの場合。

ソフトウェア構成は同様に、複数のリージョンやゾーン配置、それらにトラフィックを振り分ける辺りがポイント。

SIP and WebRTC on AWS

リージョンとAZを意識したインスタンスの配置、多数のセッションやPPSをさばくために、SR-IOVとDPDK、ENAが利用できる

専用線としてDirect Connectの利用。オンプレ側はMPLS網を構成例としていますね。

HAとスケーラビリティ

AsteriskサーバーにSecondary Private IPをフローティングIPとして付けて、APIやSDKスクリプトを使って監視、付け替え

Auto Scalingも有効。StatefulなアプリケーションにはLifecycle hookで対応する

SIPでのロードバランス。LBはSIP/TCPであればNLB、SIP/UDPはMarketplaceのパートナープロダクトで扱えるものがある。WebRTCも同様の構成図がありました。

GSLBとしてRoute 53を利用。LBRとフェイルオーバー

Auto ScalingのLifecycleにCW Events→Lambda→EC2 Systems Managerでアクションを実行。Route 53の動的なレコード操作もCW Events+Lambdaで対応可能。

音声コミュニケーションをよりリッチに

AWSの音声関連サービス、Alexaの活用など

ベストプラクティス

• SIP Overlay
• いかにSimplifyするか
• 複数リージョン利用時のリージョン間ネットワーク障害の対応
  • オレゴン-バージニア間で障害発生、カリフォルニアを迂回するように構成
  • FreePBXでのデモ
• インスタンス、AZ障害対応
  • IPの切り替え、ひとつはDNS。キャッシュされるのでフェイルオーバーが遅くなる。
  • DNSの設定例、SRVレコードの利用。迅速なフェイルオーバーが必要であればDNSはロードバランス用途にしておき、フローティングIPによるフェイルオーバーがオススメ。
  • SIP Trunkの活用。Twilio Trunkingのデモ。
• AZ Affinity
  • 特定AZに偏らないようにトラフィックを制御する
• SIPの監視
  • SIPpとiperfの組み合わせ
  • SIPpはCloudWatchに
  • 西海岸から東海岸にSIPpを実行するデモ
  • 見ておくべきメトリクスは2つ
  • Successful calls
  • SIP retransmits

所感

マルチリージョンのSIPサービスは1リージョンの日本ではなかなか難しいですが、北米の複数リージョンを活用した構成は興味深いものでした。WebRTCがほとんど出てこなかったのはちょっと残念。